Daten in Service-orientierten Anwendungen klassifizieren und repräsentieren

Vielleicht liegt es einfach am Alter des Autors, aber früher war in der IT-Welt alles viel einfacher. Als noch Rechner vom Format „Big Iron“ die Welt beherrschten, teilten sich alle von der IT-Abteilung entwickelten Anwendungen eine einzige Datenquelle, und alle Clients für diese Anwendungen basierten auf demselben Code und einer einheitlichen Plattform. Es gab keine Probleme mit dem Deployment, und der Datenaustausch zwischen Anwendungen war einfach, da diese Daten in einer leicht zugänglichen schlichten Datei oder Tabelle auf dem Mainframe existierten.

Selbst in den aufregenden Zeiten des Client-Server-Computing teilten sich die Fat-Client-Windows-Anwendungen, welche die IT-Abteilung in PowerBuilder oder Visual Basic schrieb, eine einzige relationale Datenbank (das viel gepriesene „Enterprise Data Model“) mit Service-Desktops innerhalb der Organisation. Diese Architektur ermöglichte den Anwendungen die gemeinsame Nutzung von Daten mithilfe von Transaktionen, welche die Daten einer anderen Anwendung aktualisierten.

Nun, die Zeiten haben sich geändert. Die Notwendigkeit, in der heutigen immer stärker vernetzten Welt Daten sowohl innerhalb wie außerhalb von Organisationen gemeinsam zu nutzen, Anwendungen auf Massenhardware laufen zu lassen und heterogene Clients (von Windows-Desktops bis zu anderen Websites, PDAs und Tablet PCs) zu unterstützen, hat die idyllische Situation von einst erheblich verkompliziert.

Wie bereitet man seine Anwendungen am besten auf diese schöne neue Welt vor? Dies ist die Stunde der Service-orientierten Architektur (SOA). In ihrer einfachsten Form verlangt SOA, dass die Funktionalität einer Organisation (die Funktionalität, die früher in separaten Anwendungen enthalten war) in einen Satz von Business-Services verwandelt wird. Diese Services kommunizieren mit Konsumenten und anderen internen wie externen Services, indem sie Service-Request-Meldungen erhalten („Ich möchte den Wert von X erfahren“) und Service-Response-Meldungen verschicken („Hier ist die Antwort: Y“). Es dürfte kaum überraschen, dass diese Meldungen mithilfe von XML und SOAP repräsentiert werden, damit sie unabhängig von Plattform und Geräten sind.

Wenn Architekten und Entwickler allerdings anfangen, über das Design und die Implementierung einer SOA nachzudenken, tauchen eine Reihe von Fragen auf: Welche Daten sollten die Services gemeinsam nutzen? Wie greift man auf diese Daten zu und wie werden sie gepflegt? Und wie sollten diese Daten repräsentiert werden? Der folgende Artikel soll einen Überblick über die unterschiedlichen Arten von Daten geben, die eine SOA verwendet, und darüber, wie diese Daten sowohl innerhalb als auch außerhalb eines Services repräsentiert werden können. Wer erwägt, SOA in seiner Organisation einzusetzen, erhält hier einige Richtlinien.